COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂31-JUL-76  1142	FTP:LEFAIVRE at RUTGERS-10	BUGS IN LISP 1.6 COMPILER   
C00005 00003	∂09-AUG-76  1147	FTP:LEFAIVRE at RUTGERS-10	Debugged version of COMPLR  
C00011 ENDMK
C⊗;
∂31-JUL-76  1142	FTP:LEFAIVRE at RUTGERS-10	BUGS IN LISP 1.6 COMPILER   
Date: 31 Jul 1976 (Saturday) 1442-Est
From: LEFAIVRE at RUTGERS-10
Subject: BUGS IN LISP 1.6 COMPILER
To:   DIFFIE at SU-AI

Whit-

I have no idea who (if anyone) is currently responsible for the LISP
compiler, so I'm sending this to you since your name is on the most
recent manual I've seen.  Would you please pass this on to the appropriate
person if you are not he.

I'm making a series of improvements to the UCI LISP system when I can
find the time, including an INTERLISP-like prettyprint package, an "octal
point" (Q) to get rid of the BASE/IBASE problem, a generalized CATCH/THROW
facility, and a number of other (mostly minor) changes and additions.  One
change I recently made involved making ERRSETs compile in-line, getting
rid of all of those damn SUBFUNs and their associated special vars.  It
works fine, but while fooling around with the compiler I came across a
bug having to do with special vars being bound by nested internal lambdas.
It is typified by code like the following:

	(DE BUGGY NIL
		  ((LAMBDA (L A) (FUNC) L)
		   L
		   ((LAMBDA (L) (FUNC) (CAR L)) L)))

In addition to some extra pushes and pops, L is referenced incorrectly
by both lambda exprs.  This is evidently an old bug, and also occurs when
compiling the UCI LISP editor function EDIT*.

My question: has any further debugging been done on the compiler in the
last few years (i.e., since the UCI group grabbed the compiler)?  In
particular, has this bug been fixed?  If so, I would sure like to get
a list of the fixes.

Thanks for your help.

-Rick LeFaivre

∂09-AUG-76  1147	FTP:LEFAIVRE at RUTGERS-10	Debugged version of COMPLR  
Date:  9 Aug 1976 (Monday) 1448-Est
From: LEFAIVRE at RUTGERS-10
Subject: Debugged version of COMPLR
To:   DIFFIE at SU-AI

Whit-

I wanted to thank you for the information on the compiler.  I took the
liberty of copying your COMPLR.NOT and found it quite helpful.  It
confirmed many of the things I had figured out by code reading, and
answered several questions I hadn't figured out.  I spent last week
messing around with the code, and as I got more familiar with what's
happening decided to go ahead and fix any problems I found.  I copied
COMPLR[LSP,LSP] from SAIL, and as it seemed to be a somewhat more
recent version than the one that comes with UCI LISP, I decided to work
with it (I had already concluded that I needed something like SPLDLST
anyway).

The bug which prompted all this was present in both versions of the
compiler.  I discovered that it was somewhat more general than I
had suspected -- it involved having a copy of a special variable
being placed on the PDL without being properly frozen.  This was
done by INTERNALLAMBDA, but could also be brought about via P2SETQ,
as with

	(DE BUG NIL (FUNC (SETQ L 1) (FUNC1) L))

an (L) gets pushed onto PDL, causing the last L to reference it
instead of the special cell.  I fixed this by insuring that nobody
pushes unfrozen values of special variables on the stack.  I also
made a number of other changes which fix all of the bugs which I
am aware of (i.e., all those in CTEST and CBUGS), in addition to
some of the correct but inefficient code generation (e.g., useless
pushes and pops).  I have one copy of COMPLR from SAIL intact except
for my changes, and another with modifications for UCI LISP which
I will release with my new version.  If you would be interested in
getting it, let me know (note, however, that I'm leaving for a
vacation on Nantucket tomorrow and won't be back till August 21).

Although all of the bugs seem to be out of the compiler, there is
still something which is confusing me.  The old compiler I have
has a function GUARDLOCS which is called from P2COND and P2PROG,
apparently to force any values waiting to be loaded to get a place
on the PDL before the COND or PROG is entered so that they can
shrink the stack without worrying about them.  In the newer compiler
GUARDLOCS has disappeared, with P2COND providing this service only
for those vars which will be set inside the COND.  It seems to me
that this is not necessary -- CLEAR1 will make sure that valuable
stuff gets placed on the stack before the COND is entered.  If it
is necessary for some reason, why doesn't PROG also have to do the
same thing?  I was tempted to just get rid of this all together, but
it was one of the few things I didn't really understand and was thus
hesitant to fool with it.  Are you still close enough to the compiler
to fill me in on what's going on here?

-Rick

∂09-AUG-76  1335	FTP:LEFAIVRE at RUTGERS-10	WHAT HAPPENED TO COPT? 
Date:  9 Aug 1976 (Monday) 1636-Est
From: LEFAIVRE at RUTGERS-10
Subject: WHAT HAPPENED TO COPT?
To:   DIFFIE at SU-AI

Another quick question.  When comparing some LAP code produced by the
new compiler I got from SAIL with that produced by the seemingly older
UCI compiler, I noticed that the new compiler computed a CDR when it
really didn't have to, whereas the old compiler didn't.  Upon investigation
I found that the call to COPT in CSTEP had been removed (in fact, COPT is
not used anymore).  Do you know the reason for this?  Is there any reason
I shouldn't reinstate its use?

-Rick